Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

Similarly, an ActiveX control might contain a Click event or any other event that generates an error. Once again, the error occurs while the program’s code is not running. The program cannot trap the error, so it crashes.

To prevent this from happening, you must ensure that ActiveX controls handle any errors generated by their event handlers. As usual, the code should stop to point out errors at design time. In the final compiled version, the control should properly recover from its error if it can.

If it cannot recover, the control still must not raise an error because that will crash the program. Instead, it should raise an Error event. The main program can use the control’s Error event handler to watch for errors.

For instance, the WebStocks control graphs the value of one or more stocks. It periodically updates itself using the Web. The following code shows how the WebStocks control protects the main program when its timer event handler tries to update the control.

' Define error codes for programs to use.
Private Const wstkErrorBase = vbObjectError + 1000
Public Enum sbtnErrors
    wstkWebUpdateError = wstkErrorBase + 1
    wstkInitializeError = wstkErrorBase + 2
        :
End Enum

' Declare the Error event that we raise
' when there's a problem.
Event Error(number As Long, source As String, description As String)

' When the timer control fires its event,
' update the graph data from the Web.
Private Sub tmrUpdateFromWeb_Timer()
    ' Catch any errors.
    On Error GoTo UpdateFromWebError

    ' Do whatever's necessary to update the control.
        :
    Exit Sub

UpdateFromWebError:
    ' Raise an Error event (not an Err.Raise error).
    RaiseEvent Error(wstkWebUpdateError, _
        "WebStocks.WebUpdate", _
        "Periodic Web update failed with error:" & _
        vbCrLf & Space$(8) & Format$(Err.number) & _
        "-" & Err.description)
End Sub

The main program can watch for errors using code like the following:

' Watch for errors generated by the wstkUtilities
' WebStocks control.
Private Sub wstkUtilities_Error(number As Long, _
    source As String, description As String)

    Select Case number
        Case wstkWebInitializeError
            ' Take special action for this error.
                :
        Case ...
            ' Handle other cases.
                :
        Case Else
            ' Handle unknown cases.
            MsgBox "Error " & Format$(number) & _
                " in " & source & "." & _
                vbCrLf & vbCrLf & description
    End Select
End Sub

If the WebStocks control performed an operation that caused a divide by 0 error, the program would display a message like this one:

Error -2147220503 in WebStocks.WebUpdate.

Periodic Web update failed with error:
        11-Division by zero

Handle Other Object Errors

ActiveX controls you build are not the only objects that can generate errors outside of the main program’s control. Any other control or server object that generates errors when it has not been directly called by the program can raise a potentially fatal error.

The Data control handles this problem much as is described in the previous section. When it encounters an error that cannot be trapped, it normally attempts to handle the error itself by presenting a message to the user. You can use the control’s Error event handler to override this default behavior.

For example, suppose a program contains a Data control connected to a database. It also contains a TextBox that is bound to an integer data field selected by the Data control. Now suppose the user enters the letter X into the TextBox and tries to use the Data control to move to the next record. The Data control tries to update the current record and store the value X in the integer data field. That is an invalid data conversion, so the control fails.

Instead of raising a fatal error, the Data control raises its Error event. The main program can use the control’s Error event handler to catch the error and take action. When it has finished, the program can set the Error event handler’s response parameter to tell the Data control what to do next. If the program leaves response with its default value vbDataErrDisplay, the Data control presents the generic message “Data type conversion error.” If the program sets response to vbDataErrContinue, the Data control remains silent. This gives the program a chance to fix the problem or present a message of its own.

Break on Errors

Visual Basic’s development environment provides several different options for handling errors. To set these options, select the Tools menu’s Options command. In Visual Basic 4, click on the Advanced tab. In Visual Basic 5 and 6, click the General tab. The result is a dialog similar to the one shown in Figure 12.1.

The three break options are in the upper right. If you select Break on All Errors, the program enters break mode whenever an error occurs, whether an error handler is in effect or not. This option can help you locate the source of an error before the error handler takes control.

When you select the Break in Class Module option, the program enters break mode if an error occurs inside a class object and that object has not defined an error handler. Normally in this situation, control would return to the main program’s error handlers. When this option is set, the program stops even if the main program has an active error handler defined. This option is useful for locating errors in class modules and ActiveX controls.

When you select the Break on Unhandled Errors option, the program only enters break mode if it encounters an error when no error handler is defined. This option is useful for testing code to make sure you cannot generate any uncaught errors.

Use these three options to catch errors at different stages during project development. When you are working on a class, break on errors in the class. If you cannot figure out where an error handler is being invoked, break on all errors. Once you have a class working well, break only on unhandled errors.

Figure 12.1  Selecting break options in Visual Basic 5.

Figure 12.2  Program Bad12 displaying a bitmap file.

Self-Test

Program Bad12, shown in Figure 12.2, uses no error handling. It also contains a few bugs that cause it to crash under certain circumstances. The program lets you view graphics files quickly and easily. Use the ComboBox at the bottom to specify the kinds of files you want to examine. Use the drive, directory, and file list boxes to select a graphic file. When you select a file, the program displays the image stored in the file.